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1. Introduction 

The objective of this work is to evaluate the performance of end-to-end protocol stacks including RLP-III 
reference code. This work includes the verification of the functionality of RLP code and possible 
optimization of end-to-end performance. The optimization of end-to-end performance is accomplished by 
providing MAC with appropriate QoS design parameters: trigger for burst negotiation and burst request 
parameters to optimize end-to-end performance. 

The overall work is planned to accomplish following: 

• Physical channel resource optimization for bulk traffic 

• Supplemental channel assignment strategy ^ 

• Overall end-to-end performance evaluation 

This report shows some preliminary results of physical resource optimization for bulk traffic on the forward 
link. 

2. System Assumptions 

2.1. System modeling 

OPNET is used as the simulation tool. The protocol stack used is shown in Fig. 1 . The corresponding 
framing procedure is shown in Fig. 2. The application, TCP and IP layers are implemented directly using 
the modules provided by OPNET. The RLP-III module is the reference code provided by 2Q44. The 
application segments are applied to the TCP layer. The TCP layer processes the application segments and 
provides TCP segments to the IP layer. IP datagrams are then constructed and sent to the RLP module. On 
the sender side, for every 20ms, the multiplexing layer asks for a specific amount of data from RLP based 
on the physical link rate. The RLP-III module built-in segmentation mechanism then segments that amount 
of data from the RLP-III built-in buffer (RLPQ buffer for storing I? datagrams). On the receiver side, the 
RLP-III puts all the received segments into its resequencing buffer. When all the segments of a complete IP 
datagram are received, the built-in segmentation mechanism reassembles the IP datagram and sends it up to 
the IP layer. The frame stream from the sender RLP to the receiver RLP is processed by the Frame Error 
Masks, which reflect the impact of the physical link. 



Mobile side 



Network side 



Application 



Application 



Ai 



TCP 



1 



TCP 



IP 



IP 



RLP-II1 




RLP-III 


t 








i 


L 

r 


Multiplexing 
Sublayer 




FER Mask 




Multiplexing 
Sublayer 


► 


► 



^ Fundamental channel 
Supplemental channel 

Fig. 1 . Protocol stack of the end-to-end simulator. 
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Fig. 2. Framing procedure. 



2.2. System Assumptions 

• The forward fundamental channel is used for transmitting the RLP control frames and data frames. 

• The forward supplemental channel is used for RLP data frames only. 

• The reverse fundamental channel is used for transmitting both RLP control frames and data frames. 
There is no supplemental channel is used on reverse link. 

• The forward supplemental channel is always open (no burst negotiation is considered) 

• For each simulation, the FER values are the same for reverse Fundamental Channel and forward 
Fundamental Channel & Supplemental Channel. 



2.3. Scope and Limitations of OPNET TCP and IP Modules 



The OPNET TCP module is based on Transmission Control Protocol specified in RFC793 and RPC1 122. 

The main features incorporated in this module include: 
7 • End-to-end reliability based on acknowledgments and retransmissions triggered by exponentially 
' backed-off timer 

• Flow control provided by dynamic limitation of transmissions based on the availability of remote 
buffering resources 

• Reordering of data that arrives out of sequence 

• Optional asynchronous delivery of received information through use of the TCP urgent pointer 
mechanism 

• Connection establishment and closing through three-way handshake protocols 
J^p "Slow-start" congestion avoidance and control 

Features omitted: 

Y • The quiet time mechanism for avoiding sequence number duplication after crashes 
TCP checksums are not computed 

Other proposed enhancements not supported: 
fir • Fast retransmission/fast recovery 
\| • Protection Against Wrapped Sequence Numbers 
l\ • TCP Timestarnps option 

Since the corruption in the physical link is on the frame basis and no TCP crashes were observed in our 
simulation yet, the omitted TCP features are not expected to have impact on the results shown in this report 

The OPNET IP module supports 

• IP addressing 

• IP multicasting 

• Routing 

• Fragmentation and Reassembly 

Note: please refer to RFC793 and RFC] 122 for TCP/IP terms 

2.4. Simulation parameters 

For the performance evaluation, the following conditions are assumed: 

• FTP application is used. The file is downloaded from the network side to the mobile side 

• Mean FTP file size: 600,000 bytes 

• Application segment size: 64,000 Bytes 

• TCP maximum Round-trip Time Out (RTO): 240s 

• TCP Maximum Segment Size: 1460 bytes 

• TCP Receiver Buffer Capacity: 65536 bytes 

• Delay from sender RLP to receiver RLP: 80ms 

• Forward link: one fundamental channel plus one supplemental channel 

• Reverse link: one fundamental channel 

• Mobile speed: lkm/h 

• Number of multipaths: 1 



3. Performance 

The end-to-end performance is evaluated for forward link. 

For the performance metric definitions, the following terms are used: 

D x (bits): the application data amount. 

T x (seconds): the time for transmitting D } . 

D 2 (bits): the received data from IP layer by RLP-II1 module. 

T 2 (seconds): the time for transmitting D 2 . 

R.(b/s): radio link rate (fundamental channel rate + supplemental channel rate). 
D ete i : end-to-end delay of application segment i 

U FER Rate : RF usage factor for a combination of FER and radio link rate. 

The end-to-end performance is evaluated by the following performance metrics: 

• Normalized Layer 2 throughput: L 

R 

V 

• Normalized TCP throughput: — L 

R 

• Average end-to-end delay: Mean ( D ete . ) 

• Transmission time: T 2 

• RF resource occupancy: U FER Rate x T 2 

The results shown here are the averages of 10 simulations. 

3.1 Normalized Layer 2 Throughput 

The normalized layer 2 throughput is defined as layer 2 throughput normalized to the physical link rate 
(Fundamental channel rate plus Supplemental channel rate) 
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Fig. 3. Normalized Layer 2 Throughput 

• The non-100% normalized layer 2 throughputs on a perfect channel (FER=0) at various physical link 
rates are due to the overhead at RLP and physical layer. 

• The decreased throughputs on non-perfect channels reflect the impacts of RLP retransmissions. 

• The results for the specific simulation conditions show that the throughputs at three non-perfect 
channels (FER=1%, 5% and 10%) achieve the maximum for physical link rate of 76.8kb/s. 

3.2. Normalized TCP Throughput 

The normalized TCP throughput is defined as the TCP throughput normalized to the corresponding physical 
link rate. 
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Fig. 4. Normalized TCP Throughput 




• The non-100% throughputs on a perfect channel account for the overheads at TCP, IP, RLP and 
physical layers. 

• The decreased throughputs on non-perfect channels indicate the impacts of TCP retransmissions and 
RLP retransmissions. 

• The maximums of throughputs at FER of 1%, 5% and 10% are achieved when the physical channel rate 
of 76.8kb/s is used. 

• Compared to the perfect channel, the decrease in normalized throughput caused by FER of 5% is much 
lower than that caused by FER of 10%. From the normalized TCP throughput point of view, the 
optimal FER setting point is 5% FER. 

3.3. Average End-To-End Delay 

The average end-to-end delay is defined as the mean of application segment delays. 

Average End-To-End Delay (s) 
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Fig. 5. End-to-end delay. 
• As radio link rates increase the end-to-end delays decrease, as expected. 



3.4. Transmission Time 



The transmission time is the time used for traiisrnitting an entire FTP file. During this time period, the RF 
resource allocated to this data traffic is occupied. 
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Fig. 6. Transmission Time (s) 



• Compared to the perfect channel, the increase in transmission times for 5% FER are much smaller than 
that with 10% FER for various physical link rates 



3.5. RF Resource Occupancy or RF Cost 

A more comprehensive performance metric is defined as RF Resource Occupancy. This metric is the 
product of RF capacity usage factor at a combination of FER and physical link rate and the time needed for 
transmitting an FTP file. It reflects RF resource occupancy for transmitting a file at various possible 
combinations of FER numbers and physical link rates. The RF capacity usage factor is defined as the 
average BTS power required for each combination of data rate and FER, normalized to the average power 
required for a 9.6kb/s FCH operating at 1% FER. 
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Fig. 7. RF Resource Occupancy 





For a bulk transmission, the decrease in RF resource can be expected by using FER of 5% and 10% 
setting-point, instead of FER of 1%. 



Under the system assumptions described in Section 2, the following observations are obtained: 

• The normalized TCP throughput decreases on non-perfect physical channel (FER of 1%, 5% and 1 0%) 
due to RLP retransmissions and possible TCP retransmissions. 

• The normalized TCP throughput achieves the maximum for physical link rate of 76.8 kb/s at FERs of 
1%, 5% and 10%. 

• Transmission time decreases with the increase in physical link rates. 

• The RF resource occupancy is greatly decreased by using FER of 5% and 10% for various physical link 
rates, compared with the RF resource occupancy with FER of 1%. 

• The RF resource occupancies (RF costs) at FERs of 5% and 10% are about the same. 

• The higher the physical link rate, the lower the RF resource occupancy. 

From the end-to-end performance optimization point of view, 

• Optimal FER setting point: 5%- 1 0% 

• Optimal physical link rate: 76.8 and 153.6 kb/s 



The report shows the performance evaluation concentrated on physical resource optimization for bulk 
traffic under assumptions listed in Section 2. 

The enhancements includes: 

• Consider impacts of mobile speeds on physical resource optimization for bulk traffic. 

• Study on burst negotiation strategy 

• Identify performance metrics for optimization of end-to-end performance when burst negotiation is 
considered 

• Design and develop "monitor" and "controller" to emulate burst negotiation 

• Identify appropriate Trigger ( based on RLPQ buffer observations provided by "monitor") 

• Identify appropriate burst transmission parameters 
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